Mobile devices frequently receive low-throughput and/or small amounts of data from multiple content providers/servers, such as status updates from presence services or pushed data from any of many push services known in the art, for example, push email, instant messaging, visual voicemail, and others. Such applications typically require an always-on IP connection. Each transaction puts the mobile device in a high power mode for a considerable length of time—typically between 15-30 seconds. As the high power mode can consume as much as 100× the power as an idle mode, these network-initiated applications quickly drain a battery of the mobile device. The issue has been exacerbated by the rapid increase in popularity of such applications, which are network-initiated functionalities.
Furthermore, different messages from difference services may cause a user to frequently look at his or her mobile device, which can be distracting for the user and can further drain the battery, for example, by repeatedly illuminating a display screen of the mobile device.
Conventionally this problem is solved in mobile devices with the help of a common push notification service which maintains a single long-lived connection with a push notification client running on the mobile device. In such scenarios, each Application Server is required to send its notifications to the common push notification service and the push notification service forwards the notifications to a push notification client, which in turn forwards the notifications on to the appropriate client application. The notification messages have the relevant identifiers and addressing for the Push Notification Server and Client to broker the delivery of asynchronous notifications. Such a technique has notable drawbacks, such as: (1) Single Point of Failure, that is, the Push Notification Service; (2) Security—introducing an intermediary in the communication path between the client and server introduces security holes; (3) Trust Boundaries—when considering most common mobile operating systems, such as Android or iOS, the push notification servers are hosted in security domains different from the Application Servers, and certain class of users, such as Public Safety customers, financial organizations, etc., would want to restrict flow of information outside of the security domain setup by the customer; and (4) Presence of a specialized push notification client, which may not be feasible on all types of devices.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. Those skilled in the art will further recognize that references to specific implementation embodiments such as “circuitry” may equally be accomplished via replacement with software instruction executions either on general purpose computing apparatus (e.g., CPU) or specialized processing apparatus (e.g., DSP). It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.